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1. The background to the case 

The Danish Data Protection Agency is hereby returning to this case, which 
concems access by unauthorised persons to personal data in systems for 
which the Danish National Police is data controller. 

The Danish Data Protection Agency has put questions to the Danish National 
Police in its capacities as both regulatory authority in accordance with the 
Danish Act on Processing of Personal Data 1 and as national supervisory au- 
thority for the Schengen Information System". 



J.no. 2013-632-0050 

Ref. The Danish Data Protection has primarily focused its investigations on the 

André Dybdal Pape circumstances of the Schengen Information System. 

Direct +45 3319 3223 

In response to the questions from the Danish Data Protection Agency, the 
Danish National Police has prepared statements about the security incident, 
and the Danish Data Protection Agency has received a number of reports. An 
overview of the reports received by the Danish Data Protection Agency is 
attached as Appendix to this letter. 



2. On the basis of consultation responses, reports, etc. received by the 
Danish Data Protection Agency, the Agency has established the follow- 
ing: 

In 2012, information systems that were operated at CSC on behalf of a num- 
ber of Danish authorities, which included the Danish National Police, SKAT 
(the Danish Tax authorities), the Ministry of the Economy and the Interior 
(now the Ministry of Social Affairs and the Interior) and the Agency for Mod- 
ernisation, were exposed to a hacker attack. The information systems were 
operated on a single mainframe at CSC in Valby. It has been established with 
certainty that the attack took place in the period from 9 March 2012 to 27 Au- 
gust 2012. 



A Swedish Citizen was arrested in Cambodia at the end of August 2012. Dur- 
ing the arrest, a computer belonging to the arrested Swedish Citizen was 
seized. The Swedish Citizen and the computer were subsequently handed over 
to the Swedish Police, and the Swedish Citizen was later extradited to Den- 
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mark, where in 2014, he was convicted before the Court of Frederiksberg of 
having violated Danish legislation in connection with the hacker attack. The 
conviction was upheld by a ruling of the Eastern Division of the Danish High 
Court on 17 June 2015. 

The Danish and Swedish police have examined the computer that was seized 
in Cambodia. The computer proved to hold files that could be identified as 
copies of files on the hacked mainframe at CSC in Valby. Among the files on 
the seized computer was a copy of the RACF database, which was on the 
hacked mainframe. In addition, files were found on the seized computer that 
had been copied from the Danish National Police’ s systems on the hacked 
mainframe. One of the files on the computer was determined to be a copy of a 
particular file (hereinafter referred to as 'file X '), which was located on the 
mainframe, and contains data extracted from the Schengen Information Sys- 
tem, for which the Danish National Police is data controller. 

2.1. About the hacker attack 

The hacker attack was carried out by inter alia exploiting two vulnerabilities 
in the mainframe's IBM software. Both vulnerabilities were so-called zero- 
day vulnerabilities, which means that no corrective updates exist for the vul- 
nerabilities. IBM released the first patches to fix the two zero-day vulnerabili- 
ties after the attack was over. This particular exploitation of the vulnerabilities 
could therefore not have been averted by patching. 

The hacker had gained access to the mainframe via a Webserver that could be 
accessed from the open Internet. The hacker gained a preliminary and limited 
access to the mainframe by exploiting one of the zero-day vulnerabilities in 
the IBM Webserver software. 

By then exploiting the other zero-day vulnerability in the mainframe's system 
software, the hacker was able to incrementally increase his permissions and 
assume greater control of the mainframe. This process resulted in the hacker 
gaining unrestricted access to all data and thereby access to copy, delete, 
modify and add data. During the process, one or more programs were in- 
stalled that could be used to extract data from the mainframe. In this process, 
the hacker gained sufficient permissions to be able to steal and copy 
(download) the entire RACF database from the mainframe. Access was also 
obtained to bypass logging of the actions performed, after which the hacker 
was able to exercise "stealth". 

It was found that data had been extracted to several different servers abroad 
and that the hacker had extracted several gigabytes (GB) of data, including a 
file that is a copy of file X, which contains data extracted from the Schengen 
Information System database. 

The Danish Data Protection Agency has based on the information available 
also established that file X (with its data extracted from the Schengen Infor- 
mation System) contained information about all wanted persons in the Schen- 
gen area, a total of approximately 1.2 million records with so-called Schengen 
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alerts, and that it concerns persons who are registered in accordance with arti- 
cles 95-99 of the Schengen Convention. 

A copy of file X was found on the seized computer. 

2.2. About the system involved 

2.2.1. About the mainframe's configuration 

The hacker attack was directed at a single physical computer, a so-called 
mainframe, manufactured by IBM. The mainframe was configured into four 
partitions, called LPARs (Logical Partitions). The four LPARs are referred to 
as Dll, D12, D13 and D14. " 

Systems, applications and services can be operated in an LPAR. 

The mainframe was configured so that the connected storage media (discs) 
were shared and could be physically accessed from all four LPARs. Below, 
the term 'the shared disc system' is used to denote these storage media. 

RACF is a mainframe security system developed by IBM. RACF is used, in- 
ter alia, to check the user-ids and passwords of users and administrators, and 
their permissions to use data, programs and other resources on mainframes. 

The mainframe in question was configured with a single RACF security sys- 
tem, shared across the entire mainframe, including the four LPARs. Thus, in 
this situation, the RACF controlled user-ids and passwords for all users and 
administrators and their permissions to use data, systems, programs, services 
and other resources in all four of the mainframes LPARs. 

Information about the user ids, passwords and permissions used by the RACF 
in this particular instance was stored in encrypted form in a database/file on 
the shared disc system, which was connected to the mainframe. Below, this 
database/file is referred to as 'the RACF database'. 

An active Webserver service that could be accessed from the open Internet 
was installed in LPAR Dll. The hacker exploited a vulnerability in this Web- 
server to gain initial access to the mainframe. 

2.2.2. About use of the mainframe 

The mainframe was used, inter alia, to operate information systems on behalf 
of the Danish National Police, SKAT (the Danish tax authorities), the Minis- 
try of Economic Affairs and the Interior and the Agency for Modemisation. 

The information systems that were operated on behalf of the Danish National 
Police included: the Schengen Information System, the Criminal Register, the 
Driving Licence Register, the Passports Register and the Index Register. 

The Schengen Information System included, inter alia, information about 
individuals who were wanted, forbidden entry to the Schengen area or under 
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discreet surveillance by the police or intelligence agencies pursuant to articles 
95-99 of the Schengen Convention. 

The Criminal Register contained, inter alia, information about convicted of- 
fenders and their offences. 

The Driving Licence Register contained, inter alia , information about all per- 
sons holding Danish driving licences, including the licence holder's civil reg- 
istration number and driver's licence number. 

The Passport Register contained, inter alia , information about all persons 
holding Danish passports, including the holder's civil registration number and 
pas sport number. 

The Index Register contained, inter alia , information from the Central Civil 
Register about all Danish citizens with a civil registration number. 

The Danish National Police reported that its own systems were operated in 
LP AR Dll and D14. 

Upon inquiry, the Danish National Police reported that the implicated Web- 
server that was installed and active in LP AR Dll, was intended to give access 
from the Internet to the www.tjenestemandspension.dk portal. 

The Agency for Modernisation is the data controller for the 
www.tjenestemandspension.dk internet portal. The portal is for all civil ser- 
vants with civil service pensions. The portal allows each civil servant to look 
up relevant information about his or her own civil service pension. 

The Danish Data Protection Agency has specifically asked the Danish Na- 
tional Police who (e.g. the Danish National Police or CSC) took the decision 
for the Webserver to be accessible from the Internet by users extemal to CSC's 
premises. In two instances, the Danish National Police has failed to answer 
this question. 

The following, is based on the assumption by the Danish Data Protection 
Agency that LPAR Dll has been used by both the Agency for Modernisation 
and the Danish National Police. This is supported by the information found in 
the reports held by the Danish Data Protection Agency, which State that both 
the Danish National Police and the Agency for Modernisation were using 
LPAR Dll. 

The RACF security system on the mainframe was common to the four above- 
mentioned LPARs: Dll, D12, D13 and D14. The database of the RACF secu- 
rity system (the RACF database) contained information about approximately 
85,000 user and administrator IDs, as well as details of the associated pass- 
words and permissions to use programs, services and data on the entire main- 
frame. The high number of user and administrator IDs in the RACF database 
is related to how the RACF security system was used to control users and 




5 



administrators of the systems from the Danish National Police, the Ministry of 
Economic Affairs and the Interior, SKAT and the Agency for Modernisation. 
A copy of the RACF database was found on the hacker's computer. 

2.2.3. About consistency check of data in the Schengen Information Sys- 
tem 

During the period in which the hacker attack took place, the Schengen Infor- 
mation System was structured to consist of a central system (C. SIS) with data 
from all the Schengen countries and a corresponding national system (N.SIS) 
in each country that was affiliated with Schengen. The national N.SIS also 
contained all data from all countries. The overall system worked in such a 
manner that when a country input/updated information about inter alia per- 
sons in the national N.SIS, data would be automatically forwarded to the cen- 
tral C. SIS, which at that time was physically located in Strasbourg. The in- 
formation was then forwarded from C. SIS to the N.SIS systems in the other 
countries. The purpose of this structure and its function was that central C. SIS 
and national N.SIS systems should contain the same information. In practice, 
the content of the systems could deviate, due to delays and technical failures, 
for example in connection with the mutual exchange of data. In order to com- 
pensate for and correct these discrepancies between the systems’ data content, 
periodic so-called consistency checks were performed, whereby each country 
would locally run an automated cross-referencing of data content in the na- 
tional N.SIS against a reference file forwarded from C. SIS in Strasbourg. 

The aforementioned "N.SIS" is another term for the Schengen Information 
System, which was operated on the hacked mainframe. 

The information provided by the Danish National Police indicates that consis- 
tency checks of data in the Schengen Information System were performed in 
LP AR Dll by means of a batchjob. As part of the consistency check, the data 
in the Schengen Information System database was extracted to file X. 

According to the information received, file X containing the data extracted 
from the Schengen Information System database was stored on the shared disc 
system when file X was created and remained there after the consistency 
check was performed. It has also been stated that it was possible to access file 
X containing the extracted data from all four LPARs: Dll, D12, D13 and 
Dl 4, and that two additional files were also stored, with the same content as 
file X, namely a converted file and a sorted file. These files were also for con- 
sistency check purposes, and the two files also continued to be stored on the 
shared disc system that was linked to the mainframe, after the consistency 
check had been performed. 

The file that contained information about approx. 1 .2 million records in the 
Schengen Information System, which was found on the hacker's computer 
was, as previously stated, a copy of file X containing the data extracted from 
the Schengen Information System. The Danish National Police has stated that 
file X was copied from the disc system associated with the mainframe out on 
the Internet, via LP AR Dl 1. At the same time, the Danish National Police 
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rules out the possibility that this could have happened via any of the other 
three LPARs. 

3. The Danish Data Protection Agency's assessment and conclusions 

The Danish Data Protection Agency's processing of the case raises, first and 
foremost, the folio wing questions: 

1. Did the Danish National Police, in its capacity as data controller, im- 
plement appropriate technical and organisational security measures 
to protect data against accidental or unlawful destruction, loss or de- 
terioration and against unauthorised disclosure, abuse or other proc- 

o 

essing in violation of the provisions laid down by the Act? 

2. Did the Danish National Police as responsible authority in Denmark 
for the Schengen Information System comply with its obligations as 
outlined by artic le 118 (l) 4 of the Schengen Convention, to take the 
prescribed security measures? 

These issues are dealt with in the following sections: 3.1 to 3.10. In section 
3.1 1 it will then be considered, what steps the Danish National Police has 
taken to improve the protection of personal data that is processed by CSC on 
behalf of the Danish National Police. 

Finally section 3.12 deals with the National Police’s notification to the people 
about whom information may have been disclosed to unauthorized persons. 

3.1. About zero-day vulnerabilities and the principles of isolation, separa- 
tion and in-depth defence 

In his attack, the hacker exploited two zero-day vulnerabilities. As already 
described, patching would not have remedied these vulnerabilities and pre- 
vented what happened, because corrective measures, known as patches, did 
not exist and were not developed by the supplier, IBM, until after the hacker 
attack had ceased. 

Numerous zero-day vulnerabilities exist in virtually all IT systems and they 
are discovered on an ongoing basis. This is common knowledge among IT 
professionals. The existence of vulnerabilities and especially zero-day vulner- 
abilities are a condition that must therefore always be taken into consideration 
in, inter alia : 

• the design of information systems; 

• the design of the IT systems used to run the information systems; 

• consideration and decision as to whether an information system (e.g. 
the Schengen Information System in this particular instance) can re- 
sponsibly be operated in the same mainframe as one’s other informa- 
tion systems; 
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• consideration and decision as to whether one's own information sys- 
tem (e.g. the Schengen Information System in this particular di- 
stance) should be operated in the same mainframe as other data con- 
trollers' information systems and, in this regard, share system re- 
sources with them; 

• consideration and decision as to whether an information system (e.g. 
the Schengen Information System in this particular instance) can re- 
sponsibly be operated in a mainframe that is accessible from the open 
Internet. 

Since zero-day vulnerabilities are, by their very nature, unknown, it is not 
known where they may be found in the systems, or which specific risks they 
entail. In order to accommodate this threat (and others), certain basic princi- 
ples can be applied to the design of IT systems and the use of information 
systems: 



• The principle of isolation 

• The principle of separation 

• The principle of in-depth defence 

3.2. The Danish Data Protection Agency's assessment of the information 
disclosed 

3.2.1. As previously stated, the mainframe was divided into four LPARs: 

Dl 1, D12, D13 and D14. The division of one mainframe into four LPARs 
cannot (in terms of security) be equated with operation in four separate main- 
frames that are physically isolated/separated from each other. 

The storage media (the disc system), used by the mainframe, were shared and 
could be accessed from all four LPARs: Dll, D12, D13 and D14. The weak- 
ness of this configuration is that the degree of separation depends on user 
rights, and if, like the hacker in this particular instance, somebody has gained 
unlimited permissions on the mainframe, then real access will be gained to all 
stored data. The division of one single mainframe into four LPARs with a 
shared disc system cannot (in terms of security) be equated with operation in 
four separate mainframes that are physically isolated/separated from each 
other, each with its own disc system. 

Since the Danish National Police was operating the Schengen Information 
System in one single mainframe, which was also used by other data control- 
lers for completely different purposes, the Schengen Information System was 
unnecessarily exposed to risks, which can be attributed to these other data 
controllers’ operation of their systems. 

3.2.2. An active Webserver was installed in LPAR Dll and used to serve the 
Agency for Modernisation. The Webserver could be accessed by anyone from 
the open Internet, with its presumed purpose being to grant civil servants ac- 
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cess to the www.tjenestemandspension.dk portal, so that each civil servant 
could access information about his or her own civil service pension. The 
Agency for Modernisation is data controller for 
www.tjenestemandspension.dk. 

The Danish National Police's information systems, including the Schengen 
Information System, were operated in LP AR Dl 1 and D14. Upon inquiry by 
the Danish Data Protection Agency, the Danish National Police has in two 
instances failed to provide an answer to the question of which of the informa- 
tion systems were being operated in LP AR Dll and D14, respectively. The 
Danish National Police has, however, stated that the Schengen Information 
System consistency check was performed with a batch job, and that the con- 
sistency check was run in LPAR Dll. On this basis the Danish Data Protec- 
tion Agency must assume that all information in the Schengen Information 
System was processed in LPAR Dll, and that there has been access from 
LPAR Dl 1 to all Schengen Information System data that was stored on the 
shared disc system in file X. 

The Danish National Police's Schengen Information System and the Agency 
for Modernisation's www.tjenestemandspension.dk Webserver both ran on the 
same mainframe, in the same LPAR, under the control of one and the same - 
shared - operating system. 

The hacker was able to exploit the webserver's zero-day vulnerability to gain 
initial limited access to LPAR Dll. On this basis, the hacker exploited the 
other zero-day vulnerability in the shared/common operating system in order 
to acquire further system permissions, which further led to the hacker gaining 
what amounted to administrator privileges with unlimited access throughout 
LPAR Dll, including access to the entire shared disc system, from which the 
hacker extracted a copy of file X, which contained the extract from the 
Schengen Information System. 

Exploitation of the zero-day vulnerability in the operating system resulted (as 
already mentioned) in the hacker in several stages being able to gain more 
extensive permissions. This took place in LPAR Dl 1, in the operating system 
shared by the Webserver and the Schengen Information System, i.e. shared by 
the Agency for Modernisation and the Danish National Police. It was here in 
the shared operating system that the hacker was able to "bridge" from one 
data controller (the Agency for Modernisation) to the other (the Danish Na- 
tional Police), and from one functionality (the Webserver) to the other (the 
Schengen Information System). As the hacker gained increasingly more ex- 
tensive administrator rights to the shared operating system, the division be- 
tween the Agency for Modernisation and the Danish National Police, and be- 
tween the Webserver and the Schengen Information System, was increasingly 
eroded. This should be viewed in the light of the faet that the 
www.tjenestemandspension.dk Webserver and the Schengen Information Sys- 
tem had no funetional interconnectivity and therefore had no need to share an 
operating system or LPAR, or even share a mainframe. 
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By incorporating the operation of the Schengen Information System into the 
same mainframe, in the same LP AR, and under the control of the very same 
operating system as used by the Agency for Modernisation for its Webserver, 
the Danish National Police has violated the principle of isolation and the prin- 
ciple of separation. In this instance, there was insufficient separation of the 
data controllers. Likewise, there was also an insufficient degree of separation 
between the Schengen Information System and the Webserver, which in func- 
tional terms had nothing to do with each other and therefore should not have 
been operated under the control of one and the same operating system. This 
also violated the principle of defence in depth. 

It is a widely-recognised security principle to keep a Webserver which can be 
accessed from the Internet separate from the information system containing 
the information that is to be displayed, by ensuring that the Webserver and the 
underlying information system are not operated from the same platform, or 
controlled by one and the same operating system. This principle serves to 
limit any possible exploitation of vulnerabilities in the Webserver and avoid 
contamination to the underlying information system. 

Against this background, in the view of the Danish Data Protection Agency, it 
is particularly irresponsible in security terms that the Danish National Police 
has allowed the Schengen Information System to be operated in LPAR Dl 1, 
and in LPAR Dl 1 has allowed the Schengen Information System to share the 
operating system with a Webserver that was accessible to anyone via the 
Internet. Furthermore, this is even less prudent because the Webserver was 
operated on behalf of a different data controller, and because the Webserver 
had no function with regard to the Schengen Information System. The Danish 
National Police has thereby quite unnecessarily exposed the Schengen Infor- 
mation System to a hacker attack via the Internet. 

3.3. The RACF security system manages and Controls system access and per- 
missions for users and administrators. The mainframe in question was config- 
ured with one single RACF that covered the entire mainframe, i.e. all four 
LPARs: Dl 1, D12, D13 and D14, users and administrators of the systems, 
and data for the Danish National Police, SKAT, the Ministry of Economic 
Affairs and the Interior, and the Agency for Modernisation. The use of a 
shared RACF exposed all four data controllers to greater risk from each other, 
both because the individual data controller (the Danish National Police, for 
example) became exposed to certain forms of security incidents at the other 
data controllers, and because the consequences of certain security incidents 
can spread from one data controller to the other data controllers. The Danish 
National Police has, upon inquiry, stated that in the RACF database user or 
administrator IDs existed (or could be created) with permissions to access and 
perform actions on data for which the Danish National Police is not the data 
controller. The Danish National Police has also stated that this concerns data 
for which SKAT, the Agency for Modernisation or the Ministry of Economic 
Affairs and the Interior is the data controller. 
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A copy of an RACF database was found on the computer that was seized in 
Cambodia. It has been established that this was a copy of the RACF database 
found on the mainframe in question. The RACF database contained pass- 
words and permissions for approximately 85,000 user and administrator IDs 
originating from various authorities. The Danish Data Protection Agency has 
to consider it overwhelmingly likely that the hacker was able to crack the en- 
cryption of the content of the RACF database, and thereby access the content. 

Against this background, and because the hacker is known to have acquired 
unlimited permissions to access all data on the mainframe, all data on the 
mainframe and the entire shared disc system must be considered to have been 
exposed and potentially compromised by the hacker attack. 

3.4. The mainframe had a network connection to the open Internet and was 
therefore not isolated from it. This is patently risky and raises the question of 
what security measures had been taken in this respect, with a view to counter- 
ing threats from the Internet and to establish defence in depth. 

The Danish Data Protection Agency has specifically asked the Danish Na- 
tional Police in writing which security measures the file containing the data 
extracted from the Schengen Information System and the file containing the 
RACF database had passed through on their route through the internal net- 
work at CSC from the mainframe and out to the Internet (for example, fire- 
walls, Intrusion Detection System, systematic logging and log analyses). 

To this question, the Danish National Police has answered: "Firewall cluster 
([here the Danish Data Protection Agency has omitted the names of the two 
firewalls]) IDS on Internet connections". 

The Danish Data Protection Agency understands this answer as meaning that 
some kind of firewall and a form of Intrusion Detection System had been es- 
tablished. 

In addition, the Danish Data Protection Agency has specifically asked the 
Danish National Police in writing why the security measures which the file 
containing the extract from the Schengen Information System and the file 
containing the RACF database had passed through on their route through the 
internal network at CSC from the mainframe and out to the Internet were un- 
able to prevent inter alia that the file containing the extract from the Schengen 
Information System and the file containing the RACF database were copied to 
at least one computer abroad. 

To this question, the Danish National Police has answered: "Due to functional 
customer requirements, the firewall rules (Firewall-cluster ([here the Danish 
Data Protection Agency has omitted the names of the two firewalls])) that 
were implemented at the time permitted outgoing traffic of the type in ques- 
tion. IDS on Internet connections" . 
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The Danish Data Protection Agency thus understands the Danish National 
Police's reply to mean that the firewall cluster which was to protect the main- 
frame and the information systems stored on it, including the Schengen In- 
formation System, was a security measure that the Danish National Police 
shared with other data controllers. The Danish Data Protection Agency fur- 
thermore understands that some of the rules in the firewall cluster, which de 
facto also applied to Danish National Police’s systems, had been defined to 
have a low level of protection out of consideration for the needs of other data 
controllers. This was a level of protection that, de facto, allowed anyone to 
gain access to the mainframe from the Internet. 

The Danish National Police has thus shared network security measures with 
other data controllers. By doing so, the Danish National Police has actually 
established an unnecessarily low level of protection against threats from the 
Internet, which has also led to the effective undermining of the Danish Na- 
tional Police's defence in depth of the Schengen Information System. 

3.5. The mainframe in question was configured with a single shared disc sys- 
tem, which could be accessed from all four LPARs: Dl 1, D12, D13 and D14. 
The shared disc system was used to store data for the information systems that 
were operated in all four LPARs, i.e. for the Danish National Police, SKAT, 
the Ministry of Economic Affairs and the Interior, and the Agency for Mod- 
ernisation. The use of a shared disc system placed all four data controllers at 
greater risk from each other, both because the individual data controller (the 
Danish National Police, for example) became exposed to certain types of se- 
curity incidents at the other data controllers and because the consequences of 
certain security incedents could spread from one data controller to the other 
data controllers. With regard to the separation of the data controllers and the 
separation of the data controllers’ data, the sharing of the disc system puts 
data at risk and also undermines defence in depth for all data controllers. 

For the Danish National Police, the sharing of the disc system means that data 
in the Schengen Information System (and also the Danish National Police's 
other information systems on the mainframe), has been at risk, because the 
data has been exposed to security events that could/might occur at other data 
controllers whose systems were operated in other LPARs. 

In this particular incident, the hacker had accessed and copied file X, which 
contained the data extracted from the Schengen Information System and the 
entire RACF database from the shared disc system. By accessing the shared 
disc system, the hacker had copied data belonging to other data controllers, 
for example the sections of the RACF database for which other authorities 
were data controllers. 

3.6. In this instance, the shared disc system has been shared and used by the 
Danish National Police, SKAT, the Ministry of Economic Affairs and the 
Interior and the Agency for Modernisation. In the case of the Danish National 
Police, the shared disc system was used by all Danish National Police infor- 
mation systems on the mainframe. In addition to the Schengen Information 
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System, these systems include, as previously mentioned: the Criminal Regis- 
ter, the Pas sport Register, the Driving Licence Register and the Index Regis- 
ter, which contains civil registration numbers and other personal data. These 
information systems serve different purposes. By placing the operation of 
these different information systems on the same mainframe and by allowing 
them to share LP AR Dl 1 and D14 and the same disc system, the Danish Na- 
tional Police has set up a situation in which Danish National Police informa- 
tion systems bring each other into jeopardy and increase risk, both because 
each individual information system, (for example the Schengen Information 
System) is exposed to certain types of security incidents in the Danish Na- 
tional Police's other information systems, and because the consequences of 
certain security incedents can spread from one information system to the other 
information systems. 

It has been established that data that originates from other Danish National 
Police information systems than the Schengen Information System was found 
on the computer which was seized in Cambodia. This proves that the de- 
scribed risk is a real one. 

3.7. It is apparent from the Danish National Police's response to a series of 
questions from the Danish Data Protection Agency that the file that was found 
on the hacker's computer is not an extraction of data from the Schengen In- 
formation System that was the work of the hacker in person. Rather, the file 
found on the hacker's computer is a copy of file X, which already contained 
the extraction of data from the Schengen Information System database. File X 
was stored on the mainframe's shared disc system, and had been created in 
connection with a consistency check of the Schengen Information System, 
which is performed for the purpose of ensuring the quality of data in the 
Schengen Information System. From the Danish National Police's response, 
the Danish Data Protection Agency understands that file X containing the 
extracted data from the Schengen Information System remains stored on the 
mainframe's shared disc system, until the next time the consistency check is 
performed. This practice leads to the constant presence of a file on the shared 
disc system, which contains an extraction of data in the Schengen Information 
System database. 

The Danish Data Protection Agency finds that the practice of allowing files 
containing extracted data from the Schengen Information System database to 
remain stored on the shared disc system constitutes a risk in itself, due to the 
sharing of the disc system with other data controllers. The Danish Data Pro- 
tection Agency also finds that the practice of allowing files containing ex- 
tracted data from the Schengen Information System database to continue to be 
stored after the consistency check has been performed and the files are no 
longer required to fulfil their purpose, constitutes an unnecessary risk. 

The faet that a copy of file X containing data extracted from the Schengen 
Information System was found on the hacker's computer proves that this risk 
is indeed real. 
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The faet that file X containing data extracted from the Schengen Information 
System was available to the hacker on the shared disc system made it easier 
for the hacker to obtain a copy of the content of the Schengen Information 
System database than if the hacker had to extract the data from the Schengen 
Information System database himself. All other things being equal, it is sig- 
nificantly easier to steal a stored file than it is to extract data to a file from a 
running database and subsequently succeed in taking away the file, while 
avoiding detection. 

The Danish Data Protection Agency has been informed that there were two 
additional files on the mainframe's shared disc system, and that these two files 
contained the same information from the Schengen Information System. 

These were a converted file and a sorted file. This has led to further exposure 
of the Schengen Information System. 

3.8. The exploitation of the zero-day vulnerability in the www. tjeneste - 
mandspension.dk Webserver could hardly have been avoided, but the conse- 
quences could have been kept under control and limited if simple principles of 
separation, isolation and defence in depth had been complied with. 

The faet that the hacker attack led to inter alia the transfer of information in 
the Schengen Information System to the attacker's computer in Cambodia 
should predominantly be attributed to: 

• insufficient isolation of the Schengen Information System from the 
Internet; 

• inadequate isolation/separation between the various data controllers' 
information systems and services and, accordingly; 

• overly-extensive sharing of IT system resources such as LPAR, op- 
erating system, discs and RACF between the various data controllers; 

• sharing of network security measures for the mainframe with other 
data controllers; and 

• the planning and organisation of the performance of a consistency 
check of the Schengen Information System database against the cor- 
responding Schengen database in Strasbourg in such a manner that 
files containing data extracted from the Schengen Information Sys- 
tem were stored on the shared disc system after the performance of 
the consistency check, and after the files had served their purpose. 

3.9. Summary and assessment 

In the light of the information received, the Danish Data Protection Agency 
must assume that the Danish National Police had, de facto, established and 
organised the operation of the Schengen Information System in such a way 
that: 
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• the Schengen Information System’ s operation was insufficiently 
separated from other data controllers’ information systems and ser- 
vices; 

• the security of the Schengen Information System was inadequate due 
to extensive sharing of IT system resources such as mainframe, 
LPAR, operating system, disc system and RACF with other data con- 
trollers; 

• the Schengen Information System was operated in a mainframe that 
was not isolated from the Internet; 

• the Schengen Information System was operated on the mainframe in 
an LPAR to which, completely unnecessarily, there was access for 
anyone from the open Internet to an active Webserver that was serv- 
ing of another data controller's operational requirements; 

• the network security measures for the Schengen Information System 
were inadequate, because the security measures were 
shared/common with other data controllers and had been configured 
in accordance with the operational requirements of these other par- 
ties; 

• files containing data extracted from the Schengen Information Sys- 
tem were stored after the files had fulfilled their purpose. 

The Danish Data Protection Agency finds: 

• that the Danish National Police had not implemented appropriate 
technical and organisational security measures to adequately isolate 
and separate the Schengen Information System from information sys- 
tems of other data controllers and the operation of these systems; 

• that the Danish National Police had not implemented appropriate 
technical and organisational security measures to isolate the Schen- 
gen Information System against access from the open Internet; 

• that the Danish National Police had not implemented appropriate 
technical and organisational security measures to safeguard the 
Schengen Information System against the redirection of data to the 
open Internet; 

• that the Danish National Police had not implemented appropriate 
technical and organisational security measures to delete files contain- 
ing data extracted from the Schengen Information System after the 
files had fulfilled their purpose in connection with consistency 
checks. 
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3.10. Conclusion concerning the security requirements in the Danish Act 
on the Processing of Personal Data and in the Schengen Convention 

It has been established that data in the Schengen Information System concern- 
ing all wanted persons in the Schengen area have come into the hånds of un- 
authorised parties. 

As regards the Schengen Information System, the overall view of the Danish 
Data Protection Agency is that the Danish National Police had not taken ap- 
propriate technical and organisational security measures to prevent informa- 
tion from being disclosed to unauthorised persons, misused or otherwise proc- 
es sed in violation of the law. 

The Danish Data Protection Agency finds, therefore, that the Danish National 
Police has failed to comply with the Danish Act on the Processing of Personal 
Data, Section 41(3). 

With regard to the Schengen Information System, the Data Protection Agency 
finds that the Danish National Police had not taken necessary measures to: 

• prevent the reading, copying or modification of data media by unau- 
thorised persons; 

• prevent the unauthorised input of data and the unauthorised reading, 
modification or deletion of personal data that had been input; 

• prevent the use of IT systems by unauthorised persons using data 
communication equipment. 

The Danish Data Protection Agency therefore finds that the Danish National 
Police has failed to comply with the requirements of article 118 (1) (b), (c) 
and (d) of the Schengen Convention. 

The Danish Data Protection Agency finds the lack of compliance with Section 
41(3) of the Act on the Processing of Personal Data and article 118 (1) (b), (c) 
and (d) of the Schengen Convention to be extremely open to criticism. 

In the first instance, the Danish Data Protection Agency has as previously 
mentioned focused its investigations on the circumstances of the Schengen 
Information System. However, the agency must assume that the hacker had 
unlimited permissions on the mainframe and had the opportunity to access all 
data on the mainframe's shared disc system. 

Against this background, it is the Danish Data Protection Agency's immediate 
assessment that the conclusions drawn in this letter concerning the Danish 
National Police's failure to comply with Section 41(3) of the Act on the Proc- 
essing of Personal Data with regard to the Schengen Information System are 
correspondingly also applicable to the Danish National Police's other informa- 
tion systems operated on the mainframe, including the Criminal Register, the 
Passport Register, the Driver’ s Licence register and the Index Register. 
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3.11. In its letter of 28 November 2014, the Danish Data Protection Agency 
has asked the Danish National Police to disclose whether, and to what extent, 
the Danish National Police has implemented or intends to implement systemic 
changes after the hacker attack, including those recommended by the Danish 
Security and Intelligence Service (PET) 5 . 

The Danish National Police replied by letter of 6 March 2015 that the Danish 
National Police had implemented changes to the network access to and from 
the mainframe installation, and that security in general had been reviewed, 
including procedural adjustments. Further, it was stated that the Danish Na- 
tional Police was considering certain systemic changes regarding individual 
applications on the mainframe installation, based on a comprehensive analysis 
of the continuation and modemisation of the Danish National Police's sys- 
temic legacy portfolio. Furthermore, it was stated that the Danish National 
Police, Group IT, had tightened its supervision of CSC ‘s implementation of 
the technical security measures outlined in the Centre for Cyber Security and 
the Danish Security and Intelligence Service (PET)'s report from August 2014 
concerning breach of security at CSC. 

The Danish Data Protection Agency requests to be informed of whether the 
Danish National Police has considered, or will now consider, the transfer of 
information systems for which the Danish National Police is data controller 
away from the mainframe environment in question. 

The Agency requires an answer to this question by 1 September 2015. 

3.12. Notification to the persons affected - the Act on the Processing of 
Personal Data's requirement of due diligence in data processing 
3.12.1. Notification from the Danish National Police’s to the affected per- 
sons 

It is stated that the Danish National Police on the 6 June 2013 notified the 
affected persons about the security breach by informing the general public in 
a press release and during a press conference together with the Danish Secu- 
rity and Intelligence Service (PET) and the Copenhagen Police - which was 
followed up on the same day by a press conference with the Minister of Jus- 
tice - and by informing staff members of the police via the police intranet 
POLNET. Further, it is stated that information about the compromise of the 
CPR Register has been presented in connection with the criminal case, which 
once again resulted in press coverage of the affair. Furthermore, it is stated 
that the Danish National Police has published a guide to identity theft on the 
police website. 

The Danish National Police has on the 10 September 2014, upon inquiry from 
the Danish Data Protection Agency, stated that it deemed that it had ade- 
quately complied with the requirements of due diligence in data processing, in 
relation to informing the general public about the security breach, and that the 
Danish National Police will, however once again review the issue of separate 
notification to the population in relation to the data from the Index Register 
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(which inter alia is a copy of parts of the CPR Register), after it has com- 
pleted its investigation of the security breach. 

Subsequently, the Danish National Police has stated in a letter of 6 March 
2015 that the investigation of the security breach had not yet been completed, 
and that the Danish National Police would finally assess the issue of possible 
separate information to the general public about this aspect of the security 
breach once the investigation is completed. 

3.12.2. The view of the Danish Data Protection Agency 

If personal data has come to the knowledge of unauthorised persons it is the 
view and established practice of the Danish Data Protection Agency that the 
rule in Section 5(1) of the Act on the Processing of Personal Data conceming 
due diligence in data processing, cf. Section 5(1) entails that the data control- 
ler must assess whether and, where appropriate, how the affected persons 
must be notified. 

On assessing the question of whether and how to notify, the data controller 
must inter alia consider the nature of the data and the potential consequences 
for the individuals concemed. 

The Danish Data Protection Agency must assume that that the press confer- 
ences and information that was provided in June 2013 solely concerned IT 
systems which at the time were known to be compromised. 

Even though the faet that the data from the CPR (Central Civil Register) had 
been compromised may subsequently have been communicated by certain 
media in connection with the trial in Frederiksberg, the Danish Data Protec- 
tion Agency finds that such information cannot be regarded as adequate noti- 
fication to the affected persons about how extensive an amount of data con- 
cerning all persons and businesses in Denmark unauthorized persons had ac- 
cess to. 

Thus, the Danish Data Protection Agency believes that the Danish National 
Police should have notified the affected persons about the compromise of the 
Index Register - as soon as it was known - for instance by informing the gen- 
eral public via the media or on the police website. The Danish Data Protection 
Agency finds it regrettable that this has not happened. 

Similarly, it is the Danish Data Protection Agency's opinion that the Danish 
National Police should consider whether there is cause to inform affected per- 
sons whose details were recorded in the Schengen Information System and the 
other information systems at the time of the attack. The Danish Data Protec- 
tion Agency must in this regard emphasize that, particularly in relation to the 
Schengen Information System, it must be considered that some of those regis- 
tered are not citizens in Denmark and therefore cannot be considered in- 
formed by the Danish press coverage in the summer of 2013. 



4. Concluding remarks 
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The Danish Data Protection Agency considers the protracted nature of this 
process to be very unfortunate. Even though this is to some degree attributable 
to the Agency's own case processing the Danish Data Protection Agency takes 
the view that the Danish National Police has contributed significantly to what 
has become a very protracted process. Throughout the process, the Danish 
Data Protection Agency has had to ask the same questions several times, and 
in several cases, the Agency has received answers that were unclear or in- 
complete. 

The Danish Data Protection Agency has found due cause to inform the Minis- 
try of Justice about the identified breach of both the Act on the Processing of 
Personal Data and the Schengen Convention. For your information, a copy of 
the Danish Data Protection Agency's letter (dated today) to the Ministry of 
Justice is enclosed. 

For the sake of good order, the Danish Data Protection Agency hereby States 
its intention to publish this statement on its website. 

Yours faithfully, 



Birgit Kleis 
Acting Director 
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1 Danish Act no. 429 of 31 May 2000 on the Processing of Personal Data, with subsequent 
amendments. 

2 In accordance with the, at that time, Section 2(3), of Act No. 418 of 10 June 1997 on Den- 
mark's accession to the Schengen Convention, as amended by Act No. 448 of 9 June 2004, 
the Danish Data Protection Agency has been designated as national supervisory authority in 
accordance with articles 114 and 128 of the Convention. 

3 Section 41(3) of the Act on the Processing of Personal Data requires the data controller to 
implement appropriate technical and organisational security measures to protect data 
against accidental or unlawful destruction, loss or deterioration and against unauthorised 
disclosure, misuse or other processing in violation of the provisions laid down by the Act. 

4 Pursuant to Section 2(2) of Act No. 418 of 10 June 1997 concerning Denmark's accession to 
the Schengen Convention, as amended by Act No. 448 of 9 June 2004, the Danish National 
Police is the central authority which, in accordance with article 108(1) of the Convention, is 
responsible for the national aspect of the Schengen Information System. 

The Danish National Police is thereby inter alia responsible for the fulfilment of article 118 
(1) of the Schengen Convention, as follows: 

"Article 118 

1. Each Contracting Party undertakes, in relation to its national section of the Schengen 
Information System, to adopt the necessary measures in order to: 

(a) deny unauthorised persons access to data processing equipment used for processing 
personal data (equipment access control); 

(b) prevent the unauthorised reading, copying, modification or removal of data media (data 
media control); 

(c) prevent the unauthorised input of data and the unauthorised inspection, modification or 
deletion of stored personal data (storage control); 

(d) prevent the use of automated data processing systems by unauthorised persons using 
data communication equipment (user control); 

(e) ensure that persons authorised to use an automated data processing system only have 
access to the data covered by their access authorisation (data access control); 

(f) ensure that it is possible to verify and establish to which bodies personal data may be 
transmitted using data communication equipment (communication control); 
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(g) ensure that it is subsequently possible to verify and establish which personal data have 
been input into automated data-processing systems and when and by whom the data were 
input (input control); 

(h) prevent the unauthorised reading, copying, modification or deletion of personal data 
during transfers of personal data or during transportation of data media (transport control). 

5 Sections 4 and 5 of PET's initial report of 19 July 2013 on the hacker attack on Police IT 
systems at CSC and PET and the Centre for Cyber Security's report from August 2014 about 
the security breach at CSC, Appendix 2: PET's recommendations of 12 June 2014 to the Dan- 
ish Police and the Ministry of Justice in connection with the hacker attack on Police systems 
at CSC. 




21 



Appendix: OverView of reports, etc. received by the Danish Data Protec- 
tion Agency 

1 . 

Title: 



Author: 

Date: 

Received: 

2 . 

Title: 

Author: 

Date: 

Received: 

3 . 

Title: 



Author: 

Date: 

Received: 

4 . 

Title: 



Author: 

Date: 

Received: 

5 . 

Title: CSC Denmark ASAE3000 Declaration, Independent decla- 

ration conceming CSC Denmark A/S' managed services sec- 
tors’ data centres, encompassing information technology and 
Danish National Police infrastructure 
Author: Deloitte 

Date: 1 January 2012 to 31 December 2012 

Received: 28 October 2013 

6 . 

Title: Report on the Danish CSC mainframe incident of 2012 (re- 

port by independent experts) 

ROMAB - Robert Malmgren AB 
Thursday, 9 May, 2013 
26 November 2013 



CSC Denmark A/S, Independent Auditor's statement about 
general IT Controls for selected areas of the Danish National 
Police’ s IT environments 
Deloitte 
2011 

28 October 2013 



Report on the Danish CSC mainframe incident of 2012 (re- 
port by independent experts) up to and including page 54 
out of 137. 

ROMAB - Robert Malmgren AB 
9 May 2013 
28 October 2013 



Reply to questions asked by the Schengen countries in rela- 
tion to the security breach on the Schengen Information Sys- 
tem (SIS) 

The Danish National Police 
8 July 2013 
13 September 2013 



Analysis (CSC's written report) 
CSC 

30 April 2013 
28 October 2013 



Author: 

Date: 

Received: 
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7. 




Title: 


Result of investigation concerning the Dll (Police) and D13 




(CPR) systems. 


Author: 


CSC 


Date: 


30 April 2013 


Received: 


26 November 2013 



8 . 

Title: 

Author: 

Date: 

Received: 

9. 

Title: 

Author: 

Date: 

Received: 

10 . 

Title: 

Author: 

Date: 

Received: 

11 . 

Title: Preliminary report on the security breach at CSC 

Author: Danish Defence Intelligence Service, Centre for Cyber- 

security 

Date: July 2013 

Received: 7 July 2014 

Note: The report was received in connection with the Danish Data 

Protection Agency's own operations case concerning secu- 
rity breaches at the CPR (Civil Registration System) office. 
The report was not involved in the present case until the 
preparation of the Agency's concluding statement. 



Report on the security breach at CSC 

Danish Defence Intelligence Service, Centre for Cyber- 

security 

August 2014 

14 October 2014 



Internal memo concerning the report of loss of data at CSC 
The Danish National Police, Group IT 
29 May 2013 
24 March 2014 



Preliminary report concerning hacker attack on police IT- 
systems at CSC 

Danish Security and Intelligence Service 
19 July 2013 
11 February 2014 




